Requirements Management Process
In
order for requirements management to be effective you must establish
and create an agreement with the customer on requirement changes
throughout the project. The first is requirements development, which is
the process of identifying and creating requirements based on the user
inputs and analysis. I found many different outlines when looking
for an industry standard requirements management process but all still
focused on the main topics. We will discuss those steps that are most
crucial when defining the requirements management process.
Requirements Management DefinitionThis
lays the foundation for the end product and provides a view of the
intended solution. It also provides the baseline for the design,
testing and user acceptance. The practice of requirements definition is
typically performed in the planning phase of the project right before
elicitation occurs. It ensure the project meets objectives, deadlines,
time constraints, and cost.
These are identified by asking questions like:
• What problem are we trying to resolve?
• What current and new resources do we need to solve the identified problem?
• Do your current processes provides a
solution that doesn’t fit your short or long term needs?
After this point in the project the business analyst now collects and documents the final requirements.
"Requirements
management can be simplified if initial requirements definitions are
captured in a database-based tool to enable collaborative review…
traceability and versioning/change control” Matt Light,
Research Director, Gartner (6)
Eliciting Requirements
Requirements elicitation is the practice of collecting the requirements of a system from users, customers and other stakeholders. The practice is also sometimes referred to as
"requirement gathering". (17)
During
a normal requirements elicitation effort, it is likely that inputs will
be received from numerous sources. A team member begins taking the
customers’ business needs and turns them into actual requirements
through the elicitation process. There are multiple meetings with
clients, subject matter experts, end-users of the current system, and
many other stakeholders to begin discussion about the projects goals.
One early source of risk is the misunderstanding between users and
developers of what the requirement actually is. Elicitation meetings
require a lot of interviewing and meeting management skills in order to
gather the information needed. It’s a good practice to allocate
sufficient time for gathering requirements.
When starting the elicitation process it’s important
to find out if there are any existing systems with the organization
that may be similar to the one that is being requested. These systems
that are already in place can be studied and can potentially generate a
new ideas on how the new solution should work. Another way to get a
head start on elicitation process is studying the current standard
software solutions that already exist in the market.
The
analysts who perform the elicitation must be able to manage all
stakeholders involved and not focus just on one specific group. It’s
key that all parties’ views and interests be acknowledged and
considered in fairness. It’s important that analysts be curious
and open minded in hopes to leading to fresh ideas and new
perspectives. Analysts should never be afraid to ask “why” if they are
concerned with a customer’s requirement.
Some important skills needed for effective
requirements is active listening, analyst must be able to clearly
articulate requirements, and also possess ability to align them with
the projects goal. The source of every requirement is typically from
the expert so it’s important that the analysts have an open mind and
willingness to learn and understand from them. Another potential factor
in requirements elicitation is the politics involved. I came across an
article that really provided good detail into the truth behind what
drives certain requirements and politics is certainly one of them. Even
though analysts might not agree, it’s important to understand that
analysts shouldn’t place certain stakeholders over others as it might
lead to requirements that do not represent all parties involved.
Needless to say it takes a well-rounded analyst to elicit accurate and
complete requirements from a client. Remember
elicitation should never come to an end until the project is complete,
it should be revisited throughout each phase to ensure accuracy Requirements Analysis
Requirements analysis is an important phase and can
be used to identify key stakeholders. Creating a list of key
stakeholders ensures their needs are being considered in the risk
assessment process.(3) If the client's requirements are not
properly gathered and defined according to the information provided by
all stakeholders then the rest of the project is now off track when
trying to arrive at a solution. Requirements define capabilities that a
system or a component needs to reach a solution to a defined problem.
They can be divided into two categories, functional and nonfunctional.
Functional requirements detail what a system should perform when a
specific action is taken. Nonfunctional requirements are the
performance and system constraints that affect development. It’s
important when analyzing requirements that we reduce uncertainty early
on in the project. A possible suggestion to accomplish this is working
backwards on the requirement while considering the exact conditions
that created the uncertainty. Managing Requirement Changes
Uncontrolled changes can cause many different
problem such as additional rework, lack of first time quality,
unpredictable schedules deviations and cost issues. Following a change
process can make requirement changes very easy to deal with. A
requirements change process must be able to propose, analyze, approve,
and implement any changes within a requirement during any part of the
project. It’s also important to include an impact analysis study on
what the change results might be. This allows for better understanding
of the requested change and improved planning for all phases that will
be impacted. All change requests must follow a certain process
that has been created or this effort will fail. Requirement changes may
even sometimes require renegotiating project commitments such as time,
budgets, and resources. This is where it’s important to have management
buy in on the entire requirements management process.
Traceability (Recording)
Tracing allows for someone to manage the entire life
of a requirement throughout the project. It is important to
understand how traceability helps ensure accurate delivery of clients’
needs and expectations. Tracing is more closely related to
systems development and is a discipline within requirements management
that can add a lot of value to a project. Traceability improves the
scope management within the project and could potentially prevent you
from overseeing an identified requirement. Sometimes requirements can
be missed and it can lead to huge cost increases if it’s implemented
late in a project and can also potentially cause huge delays.
Traceability also provides the ability to track the priority of all
requirements and their changes.
A
study showed that 89% of initial requirements from project kick-off
actually make it into the final product.(14) It is important to
note that traceability can be difficult to implement without the proper
tools. If you do not have the right resources it can lead to cost
overruns and its ends up not being worth the benefit as originally
assumed. Some potential best practices for traceability include
connecting test cases to the actual requirements, relating system
requirements to their stakeholder’s requirements and making sure your
low level requirements can relate to the high level requirements so you
don’t cause any delays during implementation. In a lot of industries
traceability isn’t a practice anymore it’s more of a standard operating
procedure and to some it might even be a mandate. Please note that it’s
important to trace your requirements into all phases such as design,
coding and testing phases of the project. By doing so you are
eliminating a lot of risk!Validation
According to a Project Management Institute study
that involved over 2000 practitioners, its stated organizations that
use a formal validation process see significant improvement in project
outcomes.
“We gather all the requirements and evaluate the project scope to
understand the mutual implications and validate project requirements.”
Roberta Miglioranza, PMP, Rio de Janeiro, Brazil
It’s very interesting to see how much more successful projects are when implementing validation process properly. Challenges
Like any and all project process challenges will be
encountered and it’s important they are identified and
documented. A big challenge for a lot of organizations is getting
upper level management and executive leadership to support a RM
process. Another few challenges that are encountered when creating a RM
process is that end users fail to use many of the system's
capabilities, or aren’t using them as they were intended for, or don’t
even use the system at all. Another big challenge is traceability or
lack thereof within the requirements gathering. A study done by
PTC showed that only 1% of survey respondents indicate that
requirements traceability has no impact. When 99% of your responders
agree that this is a crucial step, it must be acknowledged by
leadership.
Check out the interesting graphic below from a survey done by Standish Report.
There are many different reason that projects get
cancelled and it’s know that poor requirements management practices are
consistently in the top 5, along with poor business alignment and
strategy changes. Many sources also cited management and
technical reason why projects failed. Another big challenge is
traceability and the success of tracking it. That is why a larger
project should consider a RM tool to manage this difficult task. Change
is inevitable so it’s a good idea to be prepared to manage that
change. (21)(20
)
Best Practices
Best practices help create a standard operating
procedure that ultimately leads to better a requirements management
system. It allows you to create a change control process that
manages the entire life of any requirement. It’s also provides the
option for a version control process for the entire documentation of
any given requirement.
Some potential best practices for requirements management is listed below:
1. Create a RM standard/baseline that your organization follows
a. Management approved RM process for all projects
2. Implement a version control process for all documentation
a. all documentation is accurate and up to date
b. restrict access to authorized users
3. Create a change control process
4. Hold peer reviews to ensure accuracy
5. Avoid terms that aren’t fully understood
6. Create workshops to educate stakeholders on requirements
7. Utilize a requirements management tool ( see information below on RM Tools) RM Tools/ Software
Garnter estimates that over 80% of business analysts
use Microsoft Office to define requirements. Word can be used for text
documents, excel can handle the large data sets, vizio is used for
diagraming and visual models and PPT for presentations and flow charts.
Most companies that engage in large projects start out by tracking
their requirements by utilizing the Microsoft office tools but
eventually end up realizing that they need to transition to a more
flexible management software. Utilizing the Office suite might seem
like a great idea from a cost side but it could end up becoming
insufficient for the complex IT needs. As projects become larger
and more complex Microsoft Office is shown to be very inadequate in
meeting the needs of the business when it comes to requirements
management. RM tools offer version tracking, requirement history,
and most importantly the automatic tracking of changes at any point in
the project. It’s important to understand that some RM tools have
additional costs such as setup fees, supports fees, and even necessary
training costs. Every project manager should weigh the pros and cons of
the RM tool based on the size of the project to determine if it is
needed or the basic MS office application will suffice. Today most
requirements management tools are available via the cloud which makes
scalability an important determining factor for some companies. Please
review the video below to get a good idea of how helpful an RM software
tool like IBM DOORS can be.
SOURCES
Referred Journals
1.
Lopez, Orlando. "Requirements Management." Journal of Validation
Technology 17.2 (2011): 78-86. ProQuest. Web. 5 Oct. 2015.
2.
Cancila, Mindy. "A Comprehensive List of Management Requirements for
Organizations Using Public Cloud Services." Gartner. Gartner, INC., 2
Apr. 2015. Web. 20 Nov. 2015.
http://www.gartner.com/document/3021225?ref=solrAll&refval=158961728&qid=3f294d7ccadc3ff6bd0a0dbb084d146e#-1181870064>.
3.
Jiang, James J., et al. "The Relation of Requirements Uncertainty and
Stakeholder Perception Gaps to Project Management Performance." The
Journal of Systems and Software 82.5 (2009): 801.
ProQuest.Web. 5 Oct. 2015.
4.
Zwikael, Ofer, and Oleg Tilchin. "Effective Customer Requirements
Management using an Information Supply Based Model." Problems and
Perspectives in Management 5.4 (2007): 50,56,91
ProQuest. Web. 5 Oct. 2015.
5.
Githens, Gregory D. "Customer Centered Products: Creating
Successful Products through Smart Requirements Management." The Journal
of Product Innovation Management 18.5 (2001)
:350. ProQuest.Web. 5 Oct. 2015.
6.
Donald J. Reifer, "Requirements Management: The Search for
Nirvana", IEEE Software, vol.17, no. 3, pp. 45-47, May/June 2000,
doi:10.1109/MS.2000.10022
7.
Pozgaj, Zeljka, and Hrvoje Sertic. "RISK MANAGEMENT BASED ON
STAKEHOLDER REQUIREMENTS AS A KEY TO SUCCESSFUL SOFTWARE DEVELOPMENT
FOR NEW
ECONOMY".Jun, ProQuest. Web. 5 Oct. 2015.
8.
Fiksel, Joseph, and Frederick Hayes-Roth. "Computer-Aided
Requirements Management." Concurrent Engineering: Research and
Applications 1.2 (1993): 83-92. ProQuest. Web. 5 Oct. 2015.
9.
Carr, Joseph J. "Requirements Engineering and Management: The Key
to Designing Quality Complex Systems." The TQM Magazine 12.6 (2000):
400. ProQuest. Web. 5 Oct. 2015.
10.
Carlshamre, Pär, and Björn Regnell. "Requirements lifecycle management
and release planning in market-driven requirements engineering
processes." Database and Expert Systems Applications, 2000.
Proceedings. 11th International Workshop on. IEEE, 2000.
11.
Faulk, Stuart, et al. "The Core Method for Real-Time Requirements."
IEEE Software 9.5 (1992): 22-33. ProQuest. Web. 5 Oct. 2015.
12.
Ghoshal, Sumantra. "Bad Management Theories Are Destroying Good
Management Practices." Academy Of Management Learning & Education
4.1 (2005): 75-91. Business Source Premier. Web. 19 Oct.
2015.